Development of communications technologies has brought continuous evolution of network standards. After a new network standard is introduced, establishment of a network of this standard cannot be completed overnight, but needs to go through a gradual process from a hotspot area to a wide coverage. In addition, because a network standard of a commercial network can still serve a terminal, there is usually a voice call continuity problem when the terminal is handed over from a high-standard network to a low-standard network during a call.
Therefore, an SRVCC (Single Radio Voice Call Continuity) solution is introduced. In this solution, a terminal needs to have a capability of converting a high-standard data packet to a low-standard data packet. This may be referred to as an SRVCC capability of the terminal herein. Likewise, a high-standard CN (Core Network) network element needs to have a capability of interacting with a low-standard CN network element, to ensure call continuity. In addition, the CN network element needs to know the SRVCC capability of the terminal, and notifies a RAN (Radio Access Network) network element of the capability, so that the RAN network element starts an SRVCC procedure according to the capability. Therefore, the SRVCC solution involves SRVCC capability negotiation. The SRVCC capability negotiation includes SRVCC capability negotiation between the CN network element and the terminal, and SRVCC capability negotiation between the CN network element and the RAN network element. The SRVCC capability negotiation between the CN network element and the terminal involves a process in which the CN network element obtains the SRVCC-supporting capability of the terminal. The SRVCC capability negotiation process between the CN network element and the RN network element involves a process in which the CN network element notifies the RAN network element of SRVCC capabilities of the terminal and the CN network element.
Currently, an SRVCC process in which a terminal is handed over from an LTE (Long Term Evolution) network already deployed in a network to a 2G or 3G network is used as an example. The terminal may report capability information about whether the terminal supports SRVCC to a CN network element (MME, mobility management entity) in an attach or TAU (Tracking Area Update) procedure by using an attach request or a TAU request. The CN network element may notify, in a handover or initial context setup procedure by using an INITIAL CONTEXT SETUP REQUEST (initial context setup request) message and a HANDOVER REQUEST (handover request) message, a RAN network element (eNB, evolved NodeB) of whether the terminal has an SRVCC capability. However, when the terminal is handed over to a high-standard network by means of an inter-RAT handover, that is, handed over from a low-standard network (for example, a 2G or 3G network) to the high-standard network (for example, an LTE network), because the low-standard network does not need SRVCC capability information, the SRVCC capability information is lacking when the terminal is handed over to the high-standard network. Consequently, after the terminal is handed over to the high-standard network, the RAN network element cannot obtain the SRVCC capability information of the terminal, and cannot start an SRVCC procedure. As a result, voice call continuity cannot be ensured, and voice experience of a user is degraded.